Computer readable storage media for tiered connection pooling and methods and systems for utilizing same

ABSTRACT

Systems and methods for tiered connection pooling are disclosed herein, which may be used in a method of fulfilling user requests in an enterprise computing system. The method involving generating, by a processing unit, a first connection pool comprising one or more previously used authenticated connections with a resource; generating, by the processing unit, a second connection pool comprising one or more unused authenticated connections with the resource; and generating, by the processing unit, a third connection pool comprising one or more unauthenticated connections with the resource; receiving, by the processing unit, a request from the user device to access the resource, the resource requiring authentication for access; and fulfilling, by the processing unit, the request based on a connection from the first, second, or third connection pool.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/451,406 filed Jun. 25, 2019 which is a continuation of U.S. patentapplication Ser. No. 15/926,958, filed Mar. 20, 2018, now U.S. Pat. No.10,382,443, which is a continuation of U.S. patent application Ser. No.15/464,734, filed Mar. 21, 2017, now U.S. Pat. No. 9,961,084, which is acontinuation of U.S. patent application Ser. No. 14/334,972, filed Jul.18, 2014, now U.S. Pat. No. 9,635,005; the entireties of each are herebyincorporated by reference for all purposes.

TECHNICAL FIELD

Embodiments of the present disclosure relate generally to connectionpooling, and more specifically to tiered connection pooling.

BACKGROUND

In typical enterprise systems, an enterprise server connects to aback-end resource, such as an application, data server, or serviceprovider, in response to a request from a device of a user. In manyinstances, the back-end resource requires authentication in order tofulfill the request, and the request may be queued or ignored untilauthentication has been completed. Briefly, requiring authenticationprior to fulfilling requests may incur substantial unwanted delay. Suchdelays may be exacerbated for requests fulfilled using multiple back-endresources as authentication must be completed with each individualback-end resource.

SUMMARY

According to certain implementations, a computer hardware systemcomprises at least one processing unit coupled to a memory, which isencoded with computer executable instructions that when executed causethe at least one processing unit to: receive a request from a userdevice to access a resource, the resource requiring authentication foraccess; assign a plurality of unused authenticated connections to theuser device, the plurality of unused authenticated connections includinga first unused authenticated connection; determine whether a previouslyused authenticated connection is available, where a previously usedconnection is a connection that has previously been used to fulfill arequest provided by the user device enabling data associated with thepreviously fulfilled request to be buffered and more readily availableto fulfill a subsequent request; if the previously used authenticatedconnection is available, fulfill the request using the previously usedauthenticated connection; if the previously used authenticatedconnection is not available, determine whether the first unusedauthenticated connection is available; if the first unused authenticatedconnection is available, fulfill the request using the first unusedauthenticated connection; if the first unused authenticated connectionis not available, determine whether another of the authenticatedconnections of the plurality of unused authenticated connections isavailable; if the another of the authenticated connections is notavailable, establish a first unauthenticated connection with theresource; authenticate the first unauthenticated connection to providean unused authenticated connection; and fulfill the request using theunused authenticated connection.

In further implementations, a method of fulfilling user requests in anenterprise computing system, the method comprising: generating, by aprocessing unit, a first connection pool comprising one or morepreviously used authenticated connections with a resource, where the oneor more previously used authenticated connections are connections thathave previously been used to fulfill a previous request provided by auser device enabling data associated with the previously fulfilledrequest to be buffered and more readily available to fulfill asubsequent request; generating, by the processing unit, a secondconnection pool comprising one or more unused authenticated connectionswith the resource; and generating, by the processing unit, a thirdconnection pool comprising one or more unauthenticated connections withthe resource; receiving, by the processing unit, a request from the userdevice to access the resource, the resource requiring authentication foraccess; and fulfilling, by the processing unit, the request based on aconnection from the first, second, or third connection pool.

In yet further implementations, a computer hardware system comprises aserver; a plurality of resources accessible by one or more devices viaan authenticated connection between the server and the resource; and atiered connection pool. The tiered connection pool comprising: a firstconnection pool with one or more previously used authenticatedconnections with a first resource of the plurality of resources, wherethe one or more previously used authenticated connections have been usedto fulfill a previous request provided by a first device of the one ormore devices enabling data associated with the previous request to bebuffered and more readily available to fulfill a subsequent request; asecond connection pool with one or more unused authenticated connectionswith the first resource; and a third connection pool with one or moreunauthenticated connections with the first resource.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1-3 are schematic diagrams of back-end computing environmentsaccording to embodiments of the present disclosure.

FIG. 4 is a schematic diagram of a tiered connection pooling environmentaccording to an embodiment of the present disclosure.

FIG. 5 is a schematic block diagram of an enterprise engine according toan embodiment of the present disclosure.

FIG. 6 is a flow chart of a method for providing tiered connectionsaccording to an embodiment of the present disclosure.

FIG. 7 is a flow chart of a method for managing connections with aresource not requiring authentication according to an embodiment of thepresent disclosure.

FIG. 8 is a flow chart of a method for managing connections with aresource requiring authentication according to an embodiment of thepresent disclosure.

DETAILED DESCRIPTION

Systems and methods for tiered connection pooling are disclosed herein.Certain details are set forth below to provide a sufficientunderstanding of embodiments of the disclosure. However, embodiments ofthe disclosure may be practiced without these particular details.Moreover, the particular embodiments are provided by way of example andshould not be construed as limiting. In other instances, well-knowncircuits, control signals, timing protocols, and software operationshave not been shown in detail to avoid unnecessarily obscuring theinvention.

Disclosed embodiments generally relate to authentication. Briefly,authentication includes verifying an identity of a user of a device andin response, granting access to one or more resources, such as anapplication or database. Authentication may be performed using a numberof authentication types. The first, and most common type ofauthentication, is directed to authenticating based on knowninformation. This may include authenticating using credentials, such asa username, password, and/or authentication key. The second type ofauthentication is directed to authenticating using something possessed,such as a credit card, debit card, or smart card. The third type ofauthentication is directed to authenticating using characteristics, suchas a location or a biometric characteristic (e.g., fingerprint). In someinstances, authentication may be implemented using multi-factorauthentication. In most systems, multi-factor authentication requiressatisfaction of at least two of the three proffered authenticationtypes.

Embodiments of the present disclosure further generally relate torequests. Typically, a user may provide a request to an enterpriseserver, which may in turn fulfill the request on behalf of the user byproviding a request to a resource. By way of example, a user may requestdata from the enterprise server, and in turn, the enterprise server mayprovide one or more requests to a resource to retrieve the data from theresource. In response, the resource may provide the data to theenterprise server, which may in turn provide the data to the user.

With reference to FIG. 1, in many cases, a resource 150 may requireauthentication prior to fulfilling requests provided by the enterpriseserver 120. Accordingly, the enterprise server 120 may authenticate withthe resource 150 to acquire access to the resource 150. The enterpriseserver may authenticate with the resource 150 on behalf of a user (e.g.,using credentials associated with the user) and/or may otherwiseauthenticate with the resource 150. Requests provided prior toauthentication may be queued or ignored by the resource 150. Onceauthenticated, the enterprise server 120 may provide a request and theresource 150 may fulfill the request in response, as described.

In many cases, a request provided by a user may require that anenterprise server provide multiple requests to a resource and/or providerequests to multiple resources. By way of example, with reference toFIG. 2, in response to a request for data from a user, an enterpriseserver 120 may establish connections with each of a plurality ofresources 150 such that the enterprise server 120 may authenticate withand retrieve data from each of the resources 150.

In some examples, an enterprise server may fail to establish aconnection with a particular resource and may instead establish aconnection with a secondary or backup resource as part of a connectionfailover. With reference to FIG. 3, an enterprise server 120 may attemptto establish a connection with a resource 150 a over a network 110. Inthe event that the connection fails, for instance due to a timeout ofthe resource 150 a and/or failure of the network 110, the enterpriseserver 120 may instead establish a connection with the resource 150 b.Because the resource 150 b may serve as a secondary or backup resourceto the resource 150 a, any request intended for the resource 150 a mayinstead be fulfilled by the resource 150 b. Moreover, because secondaryand backup resources often operate using a ready-only backup/shadowfunction, connection failovers performed in this manner are typicallysoftware-routed by the enterprise server 120.

Accordingly, description of the operation of enterprise servers has beenmade herein, where, in response to requests received from users,enterprise servers may establish connections and/or authenticate withone or more resources and may further perform a connection failover inthe event that a resource is not available. In some examples, however,operating in this manner may be inefficient. As an example, establishinga connection and/or authenticating with a resource in response to arequest may result in delaying the time at which a request is fulfilled.In particular, authentication processes may incur delays including butnot limited to establishing encrypted communication and validatingcredentials. Performing software-routed failovers may incur delays dueto the delay of an enterprise server establishing a connection and/orauthenticating with a secondary resource. Thus, as will be describedbelow, in some examples, an enterprise server may establish a connectionand/or authenticate with one or more resources prior to receiving arequest. In this manner, requests may be fulfilled more efficiently.

Embodiments of the present disclosure further generally relate toconnection pooling. Connection pooling includes maintaining a pluralityof connections between an enterprise server and a resource such that theconnections may be reused as requests associated with the resource arereceived and fulfilled. In this manner, the need to establish andterminate connections in response to each request may be mitigated. Theplurality of connections may be maintained as a “pool” of connectionsand in response to each request, a connection from the pool may beutilized to fulfill the request. Once the request is fulfilled, theconnection may be returned to the pool. In the event that allconnections of a connection pool are assigned to respective requests, anew connection may be created to fulfill a request, or the request maybe queued until a connection becomes available. Once established, newconnections may be maintained in the connection pool, or may beterminated, for instance, if a limit on the number of permittedconnections in the connection pool is enforced. In some instances, aserver may maintain a connection pool for each of a plurality ofresources. Connection pooling implemented in this manner may beimplemented in accordance with programming (e.g., automatable)connectivity configurations.

FIG. 4 illustrates a computer networking environment or system 100employing authentication and tiered connection pooling according to anembodiment of the invention. Each of the plurality of user devices 102may comprise a computing device, including but not limited to a modem, arouter, a gateway, a server, a thin client, a laptop, a desktop, acomputer, a tablet, a media device, a smart phone, a cellular phone orother mobile device, or any combination or sub-combination of the same.Each of the plurality of user devices 102 may include a memory (notshown in FIG. 4) encoded with executable instructions that may operatein conjunction with one or more processing units (not shown in FIG. 4)of the user device 102. The one or more processing units may providefunctionality allowing execution of executable instructions encoded onthe memory of the user device 102. Each user device 102 may includeinstructions for execution of one or more applications that may providerequests to the enterprise server 120, described below. Providingrequests in this manner may, for instance, include requesting datastored on one or more resources 150.

Each of the user devices 102 may be configured to communicate over anetwork 110 with any number of devices, including but not limited to theenterprise server 120 described herein. The network 110 may comprise oneor more networks, such as local area networks (LANs), wide area networks(WANs), metropolitan area networks (MANs), cellular networks, and/or theInternet. Communications provided to, from, and within the network 110may wired and/or wireless, and further may be provided by any networkingdevices known in the art, now or in the future. Devices communicatingover the network 110 may communicate with any communication protocol,including TCP/IP and UDP protocols. Moreover, user devices 102 may beconfigured to communicate using known protocols such as HTTP, HTTPS,SSL, or any protocol derived therefrom.

The enterprise server 120 may include one or more processing units 121and computer readable media 123. Herein, the term computer readablemedia is used to refer to a single computer readable medium in someembodiments, and in other embodiments multiple computer readable mediain communication with one or more processing units, such as theprocessing units 121. The computer readable media 123 may storeexecutable instructions for an enterprise engine 124. The computerreadable media 123 may also include a storage 128. The executableinstructions for the enterprise engine 124 may include instructions forselectively assigning one or more tiered connections to users, furtherexamples of which are provided below. Although the executableinstructions for the enterprise engine 124 are shown on a same computerreadable media 123, in some embodiments any or all sets of instructionsmay be provided on multiple computer readable media and may not beresident on the same media. Accordingly, computer readable media 123 asused herein includes one or more computer readable media 123 and/or thestorage 128. Computer readable media 123 and/or storage 128 may includeany form of computer readable storage or computer readable memory,transitory or non-transitory, including but not limited to, externallyor internally attached hard disk drives, solid-state storage (such asNAND flash or NOR flash media), tiered storage solutions, storage areanetworks, network attached storage, and/or optical storage. Asdescribed, the instructions stored on the computer readable media 123may be executed on the one or more processing units 121 or otherprocessing units. The executable instructions for the enterprise engine124 may be referred to as a “connection engine” herein, where theconnection engine refers to the executable instructions for anenterprise engine 124 executed by the one or more of the processingunits 121 and/or other processing units.

Each of the resources 150 may be an application, a database, and/or anyother service that may be used to fulfill a request. Each of theresources 150 may communicate with the enterprise server 120 and/or oneor more user devices 102 over the network 110, and may communicate usingany protocol known in the art, including TCP/IP, UDP, HTTP, HTTPS, SSL,any protocol derived therefrom, or any combination or sub-combination ofthe same. In other instances, the resources 150 may communicate with theenterprise server 120 using other communication methodologies known inthe art, now or in the future.

In some examples, the connection engine may employ connection poolingand serve as an intermediary between the user devices 102 and each ofthe resources 150. Accordingly, the connection engine may maintain an L1connection pool for each of the resources 150, as described. Connectionsmaintained in this manner may be unauthenticated connections, or L1connections, and may be used to fulfill requests provided by the userdevices 102 and directed to resources 150 not requiring authentication.

In some instances, one or more resources 150 may require authenticationprior to fulfilling one or more requests. Accordingly, the connectionengine may authenticate users of user devices 102. In response toauthenticating a user, the connection engine may assign one or moretiered connections to the user device 102. Connections assigned in thismanner may be authenticated connections and may be used to fulfillrequests with resources 150 requiring authentication. The connectionengine may provide (e.g., generate) an authenticated connection, forinstance, by removing an L1 connection from an L1 connection pool andauthenticating the L1 connection with a resource 150. As described,connections may be authenticated using credentials provided by userdevices 102 and/or may be authenticated in any other manner.

In some examples, an authenticated connection may either be an unusedauthenticated connection or a used authenticated connection. An unusedauthenticated connection, or L2 connection, may be an authenticatedconnection that has not yet been used to fulfill any requests providedby a user device 102. A used authenticated connection, or L3 connection,may be an authenticated connection that has previously been used tofulfill one or more requests provided by a user device 102. Becauseprior fulfillment of a request may allow for subsequent requests to befulfilled more efficiently, L3 connections may result in more efficientfulfillment of requests than L2 requests. By way of example, dataassociated with a previously fulfilled request data may be buffered andtherefore more readily available to fulfill a subsequent request. Insome examples, for each authenticated user, the connection engine maymaintain one or more L2 connections in an L2 connection pool and maymaintain one or more L3 connections in an L3 connection pool.

FIG. 5 is a schematic block diagram of an enterprise engine 500according to an embodiment of the present invention. The enterpriseengine 500 may be used to implement the enterprise engine 124 of FIG. 4.The enterprise engine 500 may include a plurality of packages 515, oneor more L1 connection pools 550, and a plurality of user connectionpools 560. Each of the user connection pools 560 may include one or moreL2 connection pools 562 and/or one or more L3 connection pools 564. Eachconnection pool 550, 562, 564 may include any number of respectiveconnections.

Each of the packages 515 may be a respective set of instructions forreceiving and fulfilling various requests provided by one or more userdevices 102. During execution, each package 515 may fulfill a respectivetype of request and/or two or more packages 515 may fulfill a same typeof request. By way of example, a first package 515 may receive andfulfill requests for data associated with a particular database while asecond package 515 may receive and fulfill requests for accessing one ormore particular applications.

Briefly, in response to various requests from user devices 102, thepackages 515 may utilize connections of L1 connection pools 550, L2connection pools 562, and/or L3 connection pools 564 to provide requeststo various resources 150. As described in further detail below, L1connections of L1 connection pools 550 may be used to fulfill requestsnot requiring authentication, and each L1 connection pool 550 may beassociated with a particular resource 150. Conversely, L2 connections ofL2 connection pools 562 and L3 connections of L3 connection pools 564 ofuser connection pools 560 may be used to fulfill requests requiringauthentication. Each user authenticated with the connection engine mayhave one or more respective L2 and L3 connection pools 562, 564. Inparticular, a user may have an L2 connection pool 562 and/or an L3connection pool 564 for each resource 150 a user may access uponauthentication of the user. In this manner, the connection engine maymaintain authenticated connections for each authenticated user with anynumber of resources 150 requiring authentication.

FIG. 6 is a flow chart of a method 600 for providing tiered connectionsaccording to an embodiment of the present invention. The method 600 maybe implemented using the enterprise server 120 of FIG. 1, and inparticular, may be implemented using the connection engine of theenterprise server 120.

At a step 605, the connection engine may identify a user. As described,identifying a user may include authenticating the user in accordancewith one or more authentication methodologies such that the identity ofthe user may be verified. Identifying a user further may includedetermining which resources 150 a user may access once authenticated.The connection engine may, for instance, determine that a user mayaccess particular data of a database. As an example, a user may be apatient of a healthcare provider and access data (e.g., healthcare data)associated with the user in a database managed by the healthcareprovider. As another example, a user may be a physician, and may beauthorized to access healthcare data associated with one or more of thephysician's patients in a database managed by the healthcare provider.

Once the user has been identified at the step 605, the connection enginemay assign one or more tiered connections to the user at a step 606. Forexample, if, at the step 605, the connection engine determined that theuser may access a resource 150 requiring authentication, the connectionengine may remove an L1 connection from the connection pool associatedwith the resource 150 and authenticate the L1 connection (e.g., usingcredentials of the user) to provide an L2 connection that maysubsequently be used to fulfill requests provided by the user anddirected to the resource 150. Any number of connections may be assignedin this manner for any number of resources 150 requiring authentication.A user may, for instance, be assigned three (3) L2 connections foraccessing a first resource 150 and be assigned six (6) L2 connectionsfor accessing a second resource 150.

FIG. 7 is a flow chart of a method 700 for managing connections with aresource not requiring authentication according to one embodiment. Themethod 700 may be implemented using the enterprise server 120 of FIG. 1,and in particular, may be implemented using the connection engine of theenterprise server 120.

At a step 705, the connection engine may receive a request from a userdevice 102 for accessing a particular resource 150. The request may bean unauthenticated request, or a request directed to a resource 150 notrequiring authentication for the request to be fulfilled. Because therequest does not require authentication, at a step 710, the connectionengine may determine whether any L1 connections from the connection poolassociated with the requested resource 150 are available. That is, theconnection engine may determine if any L1 connections establishedbetween the enterprise server 120 and the requested resource 150 arecurrently not being used to fulfill other requests. If an L1 connectionestablished with the resource 150 is available, the connection enginemay use the L1 connection to fulfill the request provided by the userdevice 102 at a step 720. If no L1 connection established with theresource 150 is available, the connection engine may establish (e.g.,generate) a new L1 connection with the resource 150, and use the L1connection to fulfill the request at the step 720.

As described, once the request has been fulfilled, the L1 connectionused to fulfill the request may be returned to the connection poolassociated with the resource 150 and used to fulfill future requestsdirected to the same resource 150. In other examples, if an L1connection was established to fulfill the request, the L1 connection maybe terminated instead of being added to the connection pool. In yetother examples, the L1 connection may be migrated to an L2 or and L3connection pool, for instance, based on analysis of service requestsfrom the user.

FIG. 8 is a flow chart of a method 800 for managing connections with aresource requiring authentication according to an embodiment of thepresent invention. The method 800 may be implemented using theenterprise server 120 of FIG. 1, and in particular, may be implementedusing the connection engine of the enterprise server 120.

At a step 805, the connection engine may receive a request from a userdevice 102 for accessing a particular resource 150. The request may bean authenticated request, or a request directed to a resource 150requiring authentication for the request to be fulfilled. Because therequest requires authentication, the connection engine may determinewhether any authenticated connections associated with the requestedresource 150 and assigned to the user of the user device 102 areavailable. For example, at a step 810, the connection engine maydetermine if an L3 connection assigned to the user of the user device102 for the requested resource 150 is available. If an L3 connection isavailable, at a step 835, the connection engine 835 may use theavailable L3 connection to fulfill the request. If an L3 connection isnot available, the connection engine may determine whether an L2connection assigned to the user of the user device 102 for the requestedresource 150 is available at a step 815. If an L2 connection isavailable, at the step 835, the connection engine may use the availableL2 connection to fulfill the request.

If an L2 connection is not available, the connection engine maydetermine whether any L1 connections from the connection pool associatedwith the requested resource 150 are available at a step 820. If an L1connection is available, the connection engine may authenticate the L1connection at a step 830 to provide an L2 connection, and fulfill therequest using the L2 connection at the step 835. If no L1 connectionestablished with the resource 150 is available at the step 820, theconnection engine may establish a new L1 connection with the resource150 at a step 825. The connection engine may then authenticate the L1connection to provide an L2 connection, and use L2 connection to fulfillthe request at steps 830 and 835, respectively.

In some examples, if an L3 connection was not available at the step 810,once the request has been fulfilled, the connection ultimately used tofulfill the request may be assigned to the user of the user device 102as an L3 connection and added to an L3 connection pool of the user andassociated with the resource 150. In this manner, the L3 connection maybe used to fulfill future authenticated requests from the same userdevice 102 for the same resource 150.

While the methods 700 and 800 has been described as including particularsteps, it will be appreciated that in some instances additional stepsmay be included the methods 700, 800 and/or one or more described stepsof the methods 700, 800 may be modified or omitted. By way of example,as described, the connection engine may determine whether an L3connection is available at step 810 and may determine whether an L2connection is available at step 815. In some instances, the connectionengine may not differentiate between L2 and L3 connections such that theconnection engine may determine whether either an L2 or an L3 connectionis available at the step 810 and omit the step 815. As another example,with reference to the method 700, in response to determining that no L1connection is available, the connection engine may determine whether anyL2 or L3 connections are available prior to establishing a newconnection. If so, the connection engine may use the available L2 or L3connection to fulfill an unauthenticated request. In this manner, theconnection engine may further reduce a need to establish one or more newconnections to fulfill requests.

While examples have been described herein with respect to a user havingaccess to a resource 150 responsive to authentication, it will beappreciated that in some instances, a user may have partial access to aresource 150 responsive to authentication. For example, a user may beauthenticated such that the user may access only particular data storedon a resource 150 or utilize particular features of an applicationexecuting on a resource 150.

Further, while examples have been described herein with respect to theconnection engine maintaining various connection pools with variousresources 150, in some examples, resources 150 may maintain respectiveconnection pools for communicating with the connection engine. In thismanner, a resource 150 may determine the number and/or type ofconnections established between the resource 150 and the connectionengine.

Accordingly, the connection engine may employ self-tending processes tomanage a self-tending connection pool. That is, the connection enginemay establish and/or terminate L1, L2, and/or L3 connections as neededto fulfill various requests provided by user devices 102. In doing so,the connection engine may enforce a limit on a number of allowed L1, L2,and/or L3 connections. Limits enforced in this manner may include aglobal limit, or a limit on a number of overall connections, and one ormore other limits, including limits on a number of each type ofconnection (e.g., L1, L2, or L3) and/or a limit on a number ofconnections established with any particular resource 150. Moreover,connections managed in this manner may be stateful such that theconnections are designated as conforming to one or more conditions. Eachconnection may, for instance, be designated as an L1, L2, or L3connection and may operate according to such designation.

From the foregoing it will be appreciated that, although specificembodiments of the invention have been described herein for purposes ofillustration, various modifications may be made without deviating fromthe spirit and scope of the invention. Accordingly, the invention is notlimited except as by the appended claims.

What is claimed is:
 1. A computer hardware system comprising at leastone processing unit coupled to a memory, wherein the memory is encodedwith computer executable instructions that when executed cause the atleast one processing unit to: identify a user associated with a userdevice using a connection engine; determine that a previously usedauthenticated connection is unavailable, wherein a previously usedconnection is a connection that has previously been used to fulfill arequest provided by the user device; remove a connection of a first typefrom a first connection pool, wherein the connection of the first typeis an unused authenticated connection; assign the connection of thefirst type to the user to access a resource requiring authentication;upon the user using the connection of the first type and becomingavailable, assign the connection of the first type as a connection of asecond connection type, wherein the connection of the second type is apreviously used authenticated connection; and store the connection ofthe second type in a second connection pool separate from the firstconnection pool.
 2. The system of claim 1, wherein the instructions thatwhen executed cause the at least one processing unit to identify a userassociated with the user device using the connection engine includeinstructions that when executed cause the at least one processing unitto: authenticate the user.
 3. The system of claim 1, wherein theinstructions that when executed cause the at least one processing unitto identify a user associated with the user device using the connectionengine include instructions that when executed cause the at least oneprocessing unit to: determine which of a plurality of resources the usermay access.
 4. The system of claim 1, wherein the instructions that whenexecuted cause the at least one processing unit to determine that apreviously used authenticated connection is unavailable includeinstructions that when executed cause the at least one processing unitto: remove a connection of a third type from a third connection pool,wherein the connection of the third type is an unauthenticatedconnection; and authenticate the connection of the third type to providea connection of the first type.
 5. The system of claim 4, wherein theinstructions that when executed further cause the at least oneprocessing unit to: store the connection of the first type in the firstconnection pool.
 6. The system of claim 4, wherein the instructions thatwhen executed further cause the at least one processing unit to: beforeremoving the connection of the the third type from the third connectionpool, determine that a connection of the first type is unavailable fromthe first connection pool.
 7. The system of claim 4, wherein theinstructions that when executed further cause the at least oneprocessing unit to: determine whether a connection of the third type isavailable from the third connection pool; and if the connection of thethird type is not available, establish an unauthenticated connectionwith the resource.
 8. The system of claim 7, wherein the instructionsthat when executed further cause the at least one processing unit to:store the unauthenticated connection as a connection of the third typein the third connection pool.
 9. The system of claim 4, wherein theinstructions that when executed further cause the at least oneprocessing unit to: assign a plurality of connections of the third typeto the user device.
 10. The system of claim 4, wherein the instructionsthat when executed further cause the at least one processing unit to:use an available connection of the third type to fulfill a requestprovided by the user device directed to a resource not requiringauthentication.
 11. The system of claim 10, wherein the instructionsthat when executed further cause the at least one processing unit to:use an available connection of the first type or of the second type tofulfill the request provided by the user device directed to the resourcenot requiring authentication when a connection of the third type isunavailable.
 12. The system of claim 1, wherein the instructions thatwhen executed further cause the at least one processing unit to:establish a new connection with the resource; authenticate the newconnection; and fulfill the request using the new connection.
 13. Thesystem of claim 12, wherein the instructions that when executed furthercause the at least one processing unit to: after the new connection isauthenticated, used and becomes available, store the new connection inthe second connection pool.
 14. The system of claim 1, wherein theinstructions that when executed further cause the at least oneprocessing unit to: after the connection of the second type is stored inthe second connection pool, receive a request from the user device toaccess the resource; determine a connection of the second type isavailable from the second connection pool; and assign the availableconnection of the second type to access the resource.
 15. The system ofclaim 1, wherein the resource comprises an application, a database, oranother service used to fulfill the request.
 16. The system of claim 1,wherein the instructions that when executed further cause the at leastone processing unit to: assign a plurality of connections of the firsttype to the user device.
 17. The system of claim 1, wherein theinstructions that when executed further cause the at least oneprocessing unit to: associate the first connection pool and the secondconnection pool with the user.